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SECTION  I — ABSTRACT 

This  paper  presents  an  implementation  mechanism,  specification  language,  and  proof  techniques 
for  problems  involving  the  arbitration  of  concurrent  requests  to  shared  resources.  This  mechanism  is 
the  serializer,  which  may  be  described  as  a kind  of  protection  mechanism,  in  that  it  prevents  improper 
orders  of  access  to  a protected  resource.  Serializers  are  a generalization  and  improvement  of  the 
monitor  mechanism  of  Brinch-Hansen  and  Hoare. 

Serializers  attempt  to  systematize  and  abstract  desirable  structural  features  of  synchronization 
control  structure  into  a coherent  language  construct.  They  represent  an  improvement  in  the  modularity 
of  synchronization  over  monitors  in  several  respects.  Monitors  synchronize  requests  by  providing  a pair 
of  operations  for  each  request  type  [examples  are  STARTREAD/ENDREAD  and 
ST  ART  WRITE/ENDWRITE  for  the  readers-writers  problems].  Such  a pair  of  operations  must  be 
used  in  a certain  order  for  the  synchronization  to  work  properly,  yet  nothing  in  the  monitor  construct 
enforces  this  use.  Serializers  incorporate  this  structural  aspect  of  synchronization  in  a unified 
mechanism  to  guarantee  proper  check-in  and  check-out.  In  scheduling  access  to  a protected  resource,  it 
is  often  necessary  to  wait  in  a queue  for  a certain  condition  before  it  continues  execution.  Monitors 
require  that  a process  waiting  in  a queue  will  remain  dormant  forever,  unless  another  process  explicitly 
signals  to  the  dormant  process  that  it  should  continue.  Serializers  improve  the  modularity  of 
synchronization  by  providing  that  the  condition  for  resuming  execution  must  be  explicitly  stated  when  a 
process  enters  a queue,  making  it  it  unnecessary  for  processes  to  signal  other  processes.  Each  process 
determines  for  itself  the  conditions  required  for  its  further  execution. 

The  behavior  of  a serializer  is  defined  axiomatically  in  terms  of  causal  and  incidental  relations 
among  events  using  the  actor  message-passing  model  of  computation.  Different  versions  of  the 
readers-writers"  problems  are  used  to  illustrate  how  the  structure  of  a serializer  corresponds  in  a 
natural  way  to  the  structure  of  the  specification  of  synchronization  problems. 

In  this  paper  we  present  specification  and  proof  techniques  using  partial  orders  on  computational 
events  for  dealing  with  problems  involving  fairness,  starvation,  and  guaranteed  concurrency.  Our 
techniques  represent  a significant  advance  over  previously  developed  techniques  using  global  states. 
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SECTION  II  — PARALLELISM  in  PROBLEM  SOLVING 

Serialuers  have  been  developed  as  a modular  arbitration  primitive  for  actor  systems  to  aid 
investigating  the  issues  of  parallelism  in  problem  solving.  Conceptually  an  actor  is  an  object  that  has 
both  procedural  and  data  aspects.  The  behavior  of  a primitive  actor  such  as  a serializer  is  defined  by 
the  ordering  relationships  among  the  events  caused  by  the  actor. 

We  now  feel  that  parallelism  may  have  a more  important  role  than  previously  realized  in 
explicating  the  structure  of  higher  level  symbolic  processing.  Until  recently  it  has  been  widely  accepted 
that  parallelism  is  not  suited  for  the  higher  level  symbolic  processing  of  problem  solving.  Most 
psychological  evidence  seems  to  point  to  individual  humans  as  being  almost  entirely  serial  In  their  high 
level  problem  solving. 

Recently  the  development  of  actor  message  passing  semantics  has  brought  about  a shift  in  our 
paradigm  for  problem  solving.  Early  programs  written  to  be  expert  in  some  domain  were  thought  to  be 
analogous  to  an  individual  human  expert  who  was  expert  in  the  domain.  Most  programs  were 
developed  on  the  basis  that  there  should  be  a single  unified  coherent  intelligence  directing  all  aspects  of 
the  problem  solving  in  a serial  fashion.  The  development  of  the  actor  model  of  computation  has 
encouraged  us  to  develop  a paradigm  based  on  a society  of  experts  communicating  by  passing 
messages.  This  switch  in  paradigm  has  provided  us  with  a rich  source  of  ideas  for  problem  solving 
strategies.  We  are  attempting  to  develop  a dialogue  style  of  programming  which  places  its  emphasis  on 
the  modular  distribution  of  knowledge  and  clean  means  of  communication  becween  pieces  of  knowledge. 
Thinking  and  programming  in  this  new  paradigm  has  in  turn  caused  us  to  re-evaluate  the  case  for 
parallelism.  We  note  that  societies  often  make  good  use  of  parallelism  for  a variety  of  purposes. 

The  additional  programming  burden  imposed  by  parallelism  is  the  task  of  arbitrating  the 
activities  of  modules  running  in  parallel.  By  analyzing  the  structure  of  problem  solvers  that  attempt  to 
use  parallelism  at  the  highest  levels  of  problem  solving,  we  hope  to  further  explicate  the  structure  of 
problem  solving.  The  explication  of  a modular  arbitration  primitive  In  this  paper  should  contribute 
toward  that  aim. 

We  see  a need  for  the  development  of  language  constructs  that  are  at  least  partially  chosen  for 
their  provability.  A language  feature  providing  synchronization  should  be  designed  to  provide  usable 
axioms  about  the  possible  orders  of  events  in  a program.  The  language  feature  should  guarantee  that 
conditions  needed  to  prove  properties  of  programs  are  explicit  in  the  axioms  for  the  language  feature. 

Serializers  have  been  designed  to  facilitate  the  proof  that  schedulers  implemented  using  them 
satisfy  their  specifications  The  specifications  of  a protected  resource  typically  involve  stating  both 
integrity  and  scheduling  constraints.  An  integrity  specification  typically  takes  the  form  of  a consistency 
constraint.  A typical  example  of  an  integrity  specification  might  be  that  the  position  and  velocity  of  an 
airplane  must  be  recorded  for  the  same  instant  of  time.  A scheduling  specification  typically  takes  the 
form  of  a constraint  on  the  time  order  of  certain  events.  A typical  example  of  a scheduling 
specification  is  that  if  two  requests  to  write  in  a data  baseare  received  in  a certain  order  then  the  first 
request  received  will  be  honored  before  the  other.  We  would  like  to  be  able  to  demonstrate  how 
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implementing  protected  resources  using  serializers  makes  it  easier  to  prove  that  they  satisfy  their 
specifications.  In  particular,  we  would  like  to  develop  techniques  for  proving  that  schedulers 
implemented  using  serializers  guarantee  a reply  to  each  request  received.  Guaranteeing  that  a reply  will 
be  sent  for  every  request  received  is  a stronger  and  more  useful  property  than  merely  being  free  of 

deadly  embrace,  which  is  the  scheduling  specification  most  extensively  treated  in  the  literature  on 
synchronization. 
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SECTION  III  — SERIALIZERS 


III.l  — Concept  of  a Serializer 

In  this  section  we  will  describe  an  abstract  mechanism  called  a serializer  for  guaranteeing  the 
integrity  of  a protected  resource.  The  mechanism  is  an  abstraction  and  encapsulation  of  the  method 
commonly  used  in  operating  systems.  A detailed  analysis  of  the  facilities  needed  will  be  used  to 
motivate  our  design  decisions. 

A serializer  bears  an  analogy  to  the  front  desk  of  a hospital  in  that  only  one  person  can  check  in 
or  out  at  a time.  The  front  desk  of  a hospital  serves  to  schedule  the  entrance  and  exit  of  people  in  the 
hospital.  Entering  or  leaving  the  hospital  is  impossible  without  checking  through  the  front  desk. 
Various  queues  are  maintained  for  people  who  are  waiting.  In  addition  records  are  maintained  of 
where  people  are  within  the  hospital. 

Serializers  are  modular  in  the  sense  that  they  can  be  constructed  to  encase  the  resource  to  be 
protected  in  such  a way  that  it  can  only  be  accessed  by  passing  through  the  serializer.  A serializer 
should  be  constructed  to  surround  the  protected  resource  in  such  a way  that  It  Is  impossible  to 
accidently  avoid  passing  throueh  it  when  using  the  protected  resource.  We  shall  avoid  in  this  paper 
the  issues  involved  with  exactly  how  one  guarantees  that  a serializer  has  sole  possession  of  a resource,  or 
even  if  cooperating  serializers  might  share  access  to  a resource.  The  reader  may  assume  that  every 
serializer  we  deal  with  in  this  paper  has  sole  access  to  the  encased  protected  resource. 

We  can  diagram  how  a serializer  can  be  used  to  schedule  access  to  a protected  resource  P as  follows: 
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Diagram  of  Serializer  Encasing  a Protected  Besouroe 


Each  arrow  in  the  above  diagram  is  labeled  with  the  kind  of  computational  event  it  represents. 
The  events  fall  into  two  disjoint  categories  that  are  totally  ordered  in  time:  those  which 
GAIN-POSSESSION  and  those  which  RELEASE-POSSESSION  of  the  serialiier.  Each  event  in  the 
former  category  subsequently  causes  an  event  in  the  latter  category  to  occur.  Furthermore  after  a 
GAIN-POSSESSION  event  has  occurred,  then  another  such  event  will  not  occur  until  after  the  former 
has  caused  a RELEASE-POSSESSION  event.  A typical  sequence  of  events  occurring  in  the  use  of  the 
protected  resource  P begins  with  a SERIALIZER-REQUEST  event  in  which  the  serializer  receives  a 
message  M which  is  intended  for  the  protected  resource  P.  The  request  must  eventually  result  in  an 
ENTRY  event  which  gains  possession  of  the  serializer.  A GUARANTEE  request  can  be  used  in  order 
to  wait  until  some  condition  is  true  before  proceeding.  Such  a request  releases  possession  of  the 
serializer.  If  a reply  is  received  for  the  GUARANTEE  request  then  it  will  be  called  an  ESTABLISHED 
event  because  the  condition  is  guaranteed  to  have  been  established  at  the  time  of  the  reply.  Thus  each 
ESTABLISHED  event  regains  possession  of  the  serializer  at  a point  in  time  when  the  condition  is 
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guaranteed  to  be  true.  The  above  sequence  of  GUARANTEE  and  ESTABLISHED  events  may  occur  a 
number  of  times  in  order  to  sequentially  guarantee  a number  of  conditions  in  succession.  When  the 
proper  condition  for  using  a protected  resource  has  been  established  then  possession  of  the  serializer 
can  be  released  by  a JOIN-CROWD  event  which  records  that  there  is  another  process  in  the  crowd 
using  P.  Next  the  message  M is  delivered  to  the  protected  resource  P in  a RESOURCE-REQUEST 
event.  Eventually  the  protected  resource  P may  produce  a reply  R to  the  request  which  will  be  called  a 
RESOURCE-REPLY  event.  The  RESOURCE-REPLY  will  eventually  result  in  a LEAVE-CROWD 
event  which  regains  possession  of  the  serializer  and  records  that  the  process  is  no  longer  in  the  crowd 
using  P.  The  next  event  is  an  EXIT  event,  which  releases  possession  and  causes  a 
SERIALIZER-REPLY  event  in  which  the  message  R is  sent  as  the  reply  to  the  original 
SERIALIZER-REQUEST  event. 

Serializers  derive  their  name  from  the  fact  that  all  of  the  events  that  gain  and  release  possession 
of  the  serializer  are  totally  ordered  (serial)  in  time.  We  assume  that  every  serializer  is  written  such  that 
an  event  gaining  possession  is  always  followed  by  one  releasing  possession  (usually  this  is  trivial  to 
demonstrate).  In  the  above  diagram  the  interior  of  the  serializer  has  two  "holes*,  in  which  a process 
may  temporarily  release  possession  of  the  serializer.  The  purpose  of  the  hole  entered  by  ENQUEUE  is 
to  wait  for  some  condition  to  become  true.  The  purpose  of  the  hole  entered  by  JOIN-CROWD  is  to 
allow  parallelism  in  the  use  of  protected  resources  by  releasing  the  serializer  to  another  process.  There 
may  be  any  number  of  holes  of  either  variety. 

To  understand  the  behavior  of  serializers,  one  must  understand  the  ways  that  possession  of  a 
serializer  is  gained  and  released.  There  are  three  ways  to  gain  possession  of  a serializer: 

An  ENTRY  event,  which  gains  possession  as  a result  of  a SERIALIZER-REQUEST 
event. 

An  ESTABLISHED  event,  which  regains  possession  as  a result  of  a GUARANTEE 
request  with  a condition  established  to  be  true. 

A LEAVE-CROWD  event,  which  regains  possession  as  a result  RESOURCE-REPLY 
event  f rom  a protected  resource. 


There  are  three  ways  to  release  possession  of  a serializer: 

A GUARANTEE  event,  which  occurs  in  order  to  guarantee  that  some  condition  is  true 
before  continuing  execution. 


A JOIN-CROWD  event,  which  records  that  a process  is  using  the  protected  resource. 
An  EXIT  event,  which  causes  a reply  to  the  original  SERIALIZER-REQUEST  event. 
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For  any  given  serializer  and  process  after  an  ENTRY  event  and  before  the  corresponding  EXIT 
event,  exactly  one  of  the  following  two  conditions  will  hold: 

The  process  is  in  sole  possession  of  the  serializer  (executing  in  the  shaded  region  of  the 
diagram).  ° 

The  process  has  released  possession  in  order  to  wait  for  some  condition  before 
proceeding  or  to  join  a crowd  of  processes  executing  in  some  protected  resource. 
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SECTION  IV  — SERIALIZER  CONSTRTTflTg 

IV  .1  — Creation 

A serializer  is  constructed  by  an  expression  of  the  form 
(cr«ol«_ieriaiitcr 

{queue,:  collaction.oLqueuetJor.lha,  t«  riali»T> 

{crowd,:  collec«ion_of_crowd«Jornthg  seritliiar) 

{entry.  body_ofjtw rializar)) 

SERIAUmS^^bT^L"  “pr°n  0f  ,h'  f0rm  S1™’  *b0,e  11  * ™>“8«  “ »>  » 

;~;,rrw,nd  crowds  for  th'  ■—  * * — • ssr- jzzzxz 


LV-2  — Queues 

furthe^Sertlue'rsTovI^  ^ a"°W  * pr0CC“  l°  W%U  Until  some  cond‘tlon  "*t  before  proceeding 
provide  an  enqueue  command  which  has  the  following  syntax  to  meet  thisneed:  & 

(enqueue  the_wai<_queu« 

( guarantee ; th«_condition) 

(then:  tha_continuation)) 

enqueue^ik!  rnn.iihj!  cuARZraMr"^.^  p°“'“i°"  * >•«  ■«*.  , 

continue  with^ecutfon  of  I "«  «***"  ,nd 

following  pre  requisites  hold  ~ ESTABLISHED  th..«inilUu>n  «»ent  unt of  the 

A"  P'"'10'"  GUARANTEE  requests  In  th._w.il  ... 

the  condition  w.s  ESTABLISHED;  to  th.  protect  The  fron,  o(  Jq^e 

2:  tha_condition  is  true. 
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3:  A JOIN-CROWD,  EXIT,  or  GUARANTEE  event  has  just  occurred  releasing 
possession  of  the  serializer. 


Note  that  ajl  of  these  pre-requisites  must  be  simultaneously  satisfied  before  execution  will  continue  with 
th«  .continuation. 

It  may  be  the  case  that  there  is  more  than  one  process  which  satisfies  the  above  pre-requisites 
because  each  is  at  the  front  of  a different  queue.  In  this  case  it  is  not  obvious  which  process  should 
gain  possession  next.  We  recommend  that  serializers  be  constructed  so  that  they  satisfy  the  following 
property: 

4:  There  is  no  other  process  such  that  the  above  three  conditions  hold. 

If  all  four  conditions  hold  then  for  a process,  the  it  is  guaranteed  to  get  possession  of  the 
serializer  next  before  any  further  ENTRY  or  LEAVE-CROWD  events  occur.  In  other  words, 
conceptually  at  least,  the  condition  that  must  be  guaranteed  for  further  execution  is  evaluated  for  each 
process  that  is  at  the  front  of  a queue  every  time  possession  of  the  serializer  is  released.  If  there  is  only 
one  whose  condition  is  true  then  it  gets  possession  next. 

The  condition  in  the  guarantee:  clause  of  the  enqueue  command  is  potentially  any  Boolean 
expression  without  side  effects.  The  expression  is  evaluated  whenever  possession  of  the  serializer  is 
yielded.  We  have  found  one  particular  form  of  expression  to  be  quite  useful,  which  is  a test  for 
emptiness  of  queues  or  crowds.  This  is  written  as: 

[empty:  queue  | queueg  ...) 

Each  queue  listed  must  be  empty  for  the  expression  to  be  true.  The  evaluation  of  an  expression  of  the 
above  form  has  no  side-effects.  It  simply  calculates  the  Boolean  value  for  the  expression. 

We  wish  tho.condition  to  be  guaranteed  to  be  true  when  execution  continues  with  tho.continuation. 
This  depends  on  several  constraints: 


I:  The  evaluation  of  the.condition  is  free  of  side-effects. 

2;  The  value  of  the.condition  must  be  unaffected  by  any  execution  by  any  process  which  does 
not  possess  the  serializer. 


Given  these  constraints,  we  can  say  that  tho.condition  must  be  true  when  execution  resumes  with 
the.continuation  of  an  enqueue  command. 
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IV  -3  — Relaying  Messages 


Within  a serializer  it  is  necessary  to  be  able  to  temporarily  release  possession  of  the  serializer  in 
order  to  relay  the  message  to  the  protected  resource  and  then  later  regain  possession  with  the  reply  from 
the  protected  resource.  A command  of  the  following  form  accomplishes  this  by  transmitting  ijumiie* 
to  «_protected _resource: 

{relay _to  a_protected_ra«ource 
{menage:  a_mgtsage) 

Uhru:  a_crowd) 

{thcn_to:  continuation_for_reply)) 

An  entry  is  made  in  a_crowd  to  record  the  presence  of  a process  in  a_protactad_rasourca  and  then 
possession  is  yielded.  After  a_protacted_retource  has  replied  to  a jwttage  and  possession  of  the  serializer 
has  been  regained  by  a LEAVE-CROWD  event  then  the  entry  is  removed  from  a_crowd  and  the  reply 
received  is  sent  to  contmuationjorj-eply.  We  have  observed  that  in  many  applications  the  reply  received 
from  «-protected_resource  is  immediately  returned  as  the  value  of  the  serializer  in  an  EXIT  event. 
Therefore,  we  adopt  the  convention  that  if  the  thenjio:  clause  is  omitted  from  a reloy_jo  expression, 
then  an  EXIT  will  be  performed  with  the  message  received  from  the  protected  resource. 

During  the  time  between  the  JOIN-CROWD  and  the  LEAVE-CROWD  events,  the  entry  is  a 
member  of  a^crowd  Thus  by  inspecting  the  various  crowds  of  a serializer  it  is  possible  to  determine 
which  resources  currently  have  processes  executing  within  them.  Crowds  provide  a better  abstraction 
than  integer  counts  for  keeping  records  of  which  processes  are  currently  executing  in  protected 
resources. 
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SECTION  V — BEHAVIORAL  PROPERTIES  OF  SERIALIZERS 

The  properties  of  serializers  are  stated  somewhat  informally  in  this  paper  since  we  believe  that 
serializers  aid  intuitive  reasoning  about  parallelism.  A more  rigorous  treatment  is  possible,  but  is 
beyond  the  scope  of  this  paper. 

Behavioral  properties  of  serializers  can  be  stated  in  terms  of  events  and  relations  between  events. 
We  shall  use  the  notation 

E|  ">  E2 

to  indicate  that  the  event  Ej  precedes  the  event  E2.  The  precedes  relationship  is  an  acyclic  partial  order. 
The  events  of  processes  that  do  not  interact  are  not  ordered. 

In  the  rest  of  the  paper  we  will  require  that  the  protected  resource  is  well-behaved  in  the  sense 
that  for  each  request  sent  to  the  resource  exactly  one  reply  will  be  received. 

Another  requirement  we  will  make  is  that  every  process  that  comes  into  possession  of  a serializer 
will  eventually  release  possession.  The  intent  is  to  exclude  behaviors  where  the  serializer  is  locked  up 
forever  by  a process  which  is  performing  an  infinite  computation  while  in  possession.  We  believe  that 
this  condition  will  usually  be  trivial  to  satisfy  in  practice  since  the  code  in  a serializer  simply  has  to 
decide  whether  to  wait  for  some  condition  or  join  some  crowd  of  processes  executing  in  a protected 
resource.  This  decision  must  be  made  as  efficiently  as  possible  in  order  to  maximize  the  thruput  of  the 
serializer.  Otherwise  the  serializer  can  seriously  degrade  the  efficiency  of  a system  by  becoming  a 
bottleneck. 


V.l  — Property  of  Mutual  Exclusion 

The  most  fundamental  property  of  a serializer  is  that  processes  mutually  exclude  one  another 
from  possession  so  that  at  most  one  process  has  possession  at  any  given  instant.  For  any  given  serializer 
there  is  a total  ordering  in  time  for  all  of  the  ENTRY,  GUARANTEE,  ESTABLISHED, 
JOIN-CROWD,  LEAVE-CROWD,  and  EXIT  events  of  that  serializer.  A process  gains  possession  of  a 
serializer  starting  with  an  IJNTRY,  ESTABLISHED,  or  LEAVE-CROWD  event,  and  retains  possession 
until  it  releases  possession  with  a GUARANTEE,  JOIN-CROWD,  or  EXIT  event.  We  will  use 
subscripts  to  indicate  distinct  invocations  of  a serializer.  The  property  of  mutual  exclusion  of 
possession  of  the  serializer  can  be  stated  in  terms  of  events  as  follows: 


Either  the  i-th  possession  precedes  the  j-th  possession 
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GAIN-POSSESSION, 

I 

V 

RELEASE-POSSESSION!  ->  GAIN-POSSESSION. 

I 

V 

R ELEASE-POSSESSIONj 
or  the  j-th  possession  precedes  the  i-th. 

GAIN-POSSESSION, 

I 

V 

GAIN-POSSESSION,  <--  RELEASE-POSSESSION, 

I J 

V 

RELEASE-POSSESSION, 

where  a GAIN-POSSESSION,  event  is  either  an  ENTRY,,  ESTABLISHED,,  or  LEAVE-CROWD, 
event;  and  RELEASE-POSSESSION,  is  the  next  event  after  GAIN-POSSESSION,  which  is  a 
GUARANTEE,.  JOIN-CROWD,,  or  EXIT,  event. 


V.2  — Gaining  Possession 


We  would  like  to  guarantee  that  any  process  that  sends  a request  or  reply  to  a serializer  must 
eventually  gain  possession  of  the  serializer.  This  property  is  satisfied  by  any  serializer  that  has  no  loops 
in  which  possession  of  the  serializer  is  not  released  in  the  loop.  It  is  not  clear  that  it  is  ever  useful  to 
violate  this  restriction.  All  of  the  serializer  examples  in  this  paper  trivially  satisfy  this  restriction 
because  they  have  no  loops  at  all. 


If  the  above  restriction  is  satisfied  then  any  SERIALIZER-REQUEST  or  RESOURCE-REPLY 
event  must  eventually  result  in  a GAIN-POSSESSION  event.  More  precisely.  If  there  is  a 
SERIALIZER-REQUEST  in  the  history  of  a computation  then  it  is  followed  by  an  ENTRY  event. 
Furthermore  if  there  is  a RESOURCE-REPLY  event  in  the  history  of  a computation  then  it  is  followed 
by  a LEAVE-CROWD  event. 
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V-2  a — - First  Come  First  Served  for  Entry 

Since  serializers  are  designed  to  implement  scheduling  of  access  to  protected  resources  it  must  be 
possible  for  them  to  observe  the  order  of  arrival  of  requests  to  the  serializers  in  order  to  carry  out 
certain  scheduling  tasks.  Thus  we  provide  that  requests  for  entry  into  the  serializer  will  be  served  in 
the  order  in  which  they  arrive  at  the  serializer.  In  terms  of  events  this  can  be  formalized  by  supposing 
that  SERIALIZER-REQUEST,  and  SERIALIZER-REQUESTj  are  two  events  such  that  such  that  the 
first  arrives  before  the  second: 

SERIALIZER-REQUESTj  -->  SERIALIZER-REQUESTj 

The  next  event  after  SERIALIZER-REQUESTj  is  ENTRYj  and  the  next  event  after 
SERIALIZER-REQUESTj  is  ENTRYj.  We  require  that  these  two  events  be  related  as  follows: 

ENTRY,  ~>  ENTRYj 


V.2.b  — First  Come  First  Served  for  Re-Entry 

Similarly  it  must  be  possible  for  a serializer  to  observe  the  order  of  arrival  of  replies  to  requests 
sent  to  protected  resources.  Thus  if  RESOURCE-REPLY,  precedes  RESOURCE-REPLY j so  that 

RESOURCE-REPLY,  ~>  RESOURCE-REPLY  j 

then  we  require  that 


LEAVE-CROWD,  ~>  LEAVE-CROWDj 


V.3  — Properties  of  Guaranteed  Conditions 


V -3.a  — The  Guaranteed  Condition  is  True  if  Execution  Continues 

Let  C be  the  condition  guaranteed  in  an  event  of  the  form 

ENQUEUEq-GUARANTEEc 

which  is  caused  by  executing  an  expression  of  the  form 

(enqueue  q 

(guarantee  C) 

(then:  ...)) 

If  execution  of  the  process  continues,  then  the  next  event  of  the  process  is  of  the  form 
ESTABLISHEDq  and  C is  true  at  the  instant  of  this  event. 
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V.3.b  — Internal  Queues  are  First  In  First  Out 

Suppose  that  q is  an  internal  queue  of  the  serializer  S and  that  there  are  two  events  such  that 

ENQUEUEq-GUARANTEEcl  ~>  ENQ]UEUEq-GUARANTEEC2 

E:Tlithe  f0rmer  precedes  the  ,atter  in  the  ordering  of  the  serializer]  and  that 
rciTn,  02  i$  the  neXt  CVent  after  ENaUEUE  -CUARANTEEC2.  Then  there  is  an  event 

ESTABLISHED^  which  is  the  next  event  after  ENQUEUEq-CUARANTEEci  such  that 

ESTABLISHED^^  ~>  ESTABLISHEDC2 

which  says  that  ENQ,UEUEq-GUARANTEEcl  was  served  before  ENQ,UEUEa*GUARANTEEC2  since 
both  guarantee  requests  were  placed  in  the  same  queue.  * 

V.3.c  — Priority  for  Waiting  Processes 

Each  time  possession  of  a serializer  is  released,  waiting  processes  are  given  the  opportunity  to 
continue  execution.  This  property  of  serializers  simplifies  proofs  that  a scheduler  guarantees  replies  to 
requests  received  and  increases  the  responsiveness  of  schedulers  by  allowing  waiting  processes  to  proceed 
as  soon  as  possible.  Roughly  speaking,  if  there  are  any  waiting  processes  "ready  to  go"  when  possession 

released  then  the  next  event  t0  Sain  possession  of  the  serializer  must  be  an 
ESTABLISHED  event  which  gives  one  of  those  processes  possession.  In  terms  of  events,  a process  will 
be  said  to  be  "ready  to  go”  at  the  instant  of  a RELEASE-POSSESSION  event  if  it  is  waiting  because  of 
a previous  ENQUEUEq-GUARANTEEc  event,  but  the  corresponding  ESTABLISHED  event  has  not 
yet  occurred  and  the  following  properties  hold: 

I:  The  condition  C is  true. 

2:  The  process  is  at  the  front  of  the  queue.  Therefore  all  previous  events  that  waited 
for  some  condition  on  Q have  already  continued  with  their  condition  ESTABLISHED. 

The  above  properties  give  internal  queues  priority  over  external  queues. 


L 
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SECTION  VI  — RELATIONSHIP  TO  SEMAPHORES 


VI.l  — Mutual  Exclusion 


One  of  the  most  common  uses  of  semaphores  is  to  implement  mutual  exclusion  of  execution  in 
protected  resources.  It  is  relatively  easy  to  implement  mutual  exclusion  using  a semaphore.  The  idea  is 
for  each  process  to  perform  a P operation  on  the  semaphore  before  using  the  resource  and  then  to 
perform  a V operation  when  finished  using  the  resource.  The  program  mutual_«xclusion_l  given  below 
can  be  used  to  construct  systems  that  insure  that  a resource  does  not  receive  any  messages  while  still 
processing  a previous  message.  Thus  processes  are  guaranteed  to  mutually  exclude  each  other  from 
overlapping  execution  in  the  protected  resource.  This  simple  example  is  presented  to  illustrate  more 
concretely  the  concept  of  encasing  a resource  in  a serializer. 

(mutual  .exclusion.  1 =resource)  = jmuiuoi  exclusion  of  a resource  is  enforced  by 

(/et  (mutex  = {create  ^binary semaphore))  constructing  a new  binary  semaphore  called  mutex 

in  (=>  =a_message  ;then  returning  an  actor  such  that  uheneoer  it  receives  a menage 

(P  mutex)  ; per  forms  a P operation  on  mutex 

{let  (result  = (resource  <=  •.message))  ;then  sends  the  menage  to  the  re  tour ce 

in  ituch  that  after  the  reiuli  is  received 

{V  mutex)  ;a  V operation  it  performed  on  the  temaphore 

result)))  ;and  the  remit  it  returned 

Semaphores  are  a very  primitive  synchronization  method  which  can  be  used  to  implement  the 
facilities  needed  by  modular  schedulers.  In  some  ways  semaphores  are  analogous  to  the  goto  construct 
which  can  be  used  to  implement  the  control  structures  needed  for  modular  programming.  Serializers 
abstract  the  control  structure  of  schedulers  such  as  the  simple  one  presented  above.  They  can  be  used  to 
increase  the  modularity  of  implementations  by  making  the  structure  of  the  implementation  more  closely 
match  the  structure  of  the  task  to  be  accomplished.  In  this  way  the  synthesis  of  schedulers  from 
specifications  is  facilitated  because  serializers  provide  facilities  for  directly  implementing  common 
aspects  of  specifications  for  schedulers.  Furthermore  proofs  that  implementations  satisfy  their 
specifications  is  facilitated  because  the  structure  of  the  serializer  guarantees  many  properties  of  the 
implementation  that  would  otherwise  have  to  be  painfully  extracted  from  a global  analysis  of  the 
implementation. 

The  fundamental  integrity  constraint  for  mutual  exclusion  of  the  use  of  a resource  is  that  if  two 
requests  SERIALIZER-REQl)EST|  and  SERIALIZER>REQJUESTj  are  made  to  the  serializer  then 
either  the  i-use  completely  precedes  the  j-use 

RESOURCE-REQUEST, 

V 

RESOURCE-REPLY  j 
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or  the  j-use  completely  precedes  the  i-use. 

R“REaU“Tj 

V 

RESOURCE-REQUEST!  <--  RESOURCE-REPLY! 

I J 

V 

RESOURCE-REPLY, 

which  says  that  one  process  must  enter  and  leave  the  protected  resource  before  the  other  enters. 


(imitual_«xcltis»on_2  =r«sourc«)  s 
(create  _*criali  ter 
(queue*:  q) 

( croud s:  c) 

(entry. 

(s> 

(enqueue  q 

(guarantee:  (empty,  c)) 
(then: 

(relay_to  resource 

(message:  a_messa(e) 
(thru:  €))))))) 


;to  enforce  mutual  exclusion  for  • resource 
construct  a serial  iter 
{teilh  one  queue  q 
;and  one  croud  t 
;such  that  uhen  entry  is  gained  to  the  serializer 

;uith  a message 
ithen  i eait  on  q 
{for  the  condition  that  the  croud  c is  empty 

ithen 

;seni  to  the  resource 
;the  message  received  by  the  serializer 
ipassing  through  the  crowed  c 


It  is  easy  to  see  that  mutu«l_exc(usion_2  implements  the  integrity  specification  given  above.  The 
following  invariant  is  true  each  time  a process  gains  or  releases  possession: 


((•lie  c)  i 1) 

The  only  way  to  enter  the  resource  through  the  serialiier  is  to  pass  through  the  crowd  e.  Furthermore 
the  crowd  is  guaranteed  to  be  empty  whenever  a message  is  relayed  to  the  resource. 

Actually  mutuaLoxclusion^  implements  a stronger  specification:  namely  that  if 


SERIALIZER-REQUEST,  -->  SERIALIZER-REQUESTj 
then 


RESOURCE-REQUEST, 

I 

V 

RESOURCE-REPLY,  ->  RESOURCES-REQUESTj 

The  proof  of  this  stronger  specification  is  given  below.  If  we  suppose  that 
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SERIALIZER-REQUEST, 

then 

SERIALIZER-REQUEST, 

I 

V 

ENTER: 


— > 


SERIALIZER-REQUEST 


J 


SERIALIZER-REQUEST, 

I J 


ENQUEUE, 


J 


V 

ENTER 

I 

V 

ENQUEUE 


j 

follows  from  mutual  exclusion  for  serializers.  Therefore 

ENQUEUE, 

I 

V 

DEQUEUE,  -->  ENQUEUE, 

I 

V 

DEQUEUEj 

"""  queue,  of  a ser, aider  are  flrsHn-f,,,,™,,  since  serlalicm  exclusive  we  know  thu 

dequeue. 


JOIN-CROWD, 

Therefore 

JOIN-CROWD, 


— > 


DEQUEUE 


J 


LEAVE-CROWD: 


DEQUEUE 


J 


“ ,hM  ,he  crowd  mu“ * nw  - - - - 
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JOIN-CROWDj 

I 

V 

RESOURCE-REQUEST, 

I 

V 

RESOURCE-REPLY, 

I 

V 

LEAVE-CROWD, 


One  extremely  common  specification  is  that  an  actor  must  reply  to  each  request  it  receives  (a 
guarantee  of  service  that  implies  that  the  actor  is  starvation-free  and  thus  free  of  deadlock).  For 
serializers  this  is  expressed  in  terms  of  events  by  simply  requiring  that  for  every 
SERIALIZER-REQUEST  event  there  is  a corresponding  SERIALIZER-REPLY  event  in  the  history. 
Similarly  the  resource  can  be  required  to  reply  to  requests  by  specifying  that  for  every 
RESOURCE-REQUEST  event  there  is  a corresponding  RESOURCE-REPLY  event  in  the  history.  A 
serializer  constructed  using  mutual_axclu«ion_2  is  guaranteed  to  reply  to  requests  provided  that  the 
resource  it  encases  is  guaranteed  to  reply  to  requests. 

The  code  for  nuitual_«xclusk>n_l  looks  slightly  shorter  than  the  code  for  mutuaL«xcluaion_2,  but  that 
is  largely  due  to  the  extra  words  that  indicate  the  structure  of  rmjtual_axcluak>n_2.  In  mutual_«xcluaion_l 
the  semaphore  bookkeeping  is  explicit  for  the  message  passing  to  and  from  the  resource.  In 
mutual_»xclusion_2  the  required  bookkeeping  is  implicit  in  the  structure  of  the  language  construct. 


DEQUEUEj 

V 

JOIN-CROWDj 


RESOURCE-REQUEST . 
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SECTION  VII  — READERS-WRITERS  PROBLEMS 


VH.l  — Readers- Writers  Integrity  Specification 

A readers-writers  serializer  is  intended  to  protect  the  integrity  of  a resource  by  scheduling  access 
to  the  resource  in  such  a way  that  it  is  impossible  for  two  processes  to  overlap  in  their  use  of  the 
resource  if  one  of  them  is  a writer.  An  event  in  which  a message  is  received  by  the  protected  resource  is 
called  a RESOURCE-REQUEST,  of  which  there  are  two  special  cases:  RESOURCE-READ  and 
RESOURCE-WRITE.  In  response  to  these  requests  the  protected  resource  will  produce  responses  which 
will  be  called  RESOURCE-REPLY  events. 

The  integrity  specification  for  a readers-writers  serializer  1$  that  “a  write  request  excludes  all  other 
requests  from  the  resource".  This  integrity  specification  can  be  expressed  in  event  terms  as  follows:  if 
SERIALIZER-WRITE,  and  SERIALIZER-REQUEST,  are  two  requests  received  by  the  serializer  then 
either 

RESOURCE-WRITEj  — > RESOURCE-REPLY,  — > 

RESOURCE-REQUESTj  — > RESOURCE-REPLY j 

or 

RESOURCE-REQUEST:  ~>  RESOURCE-REPLY.  ~> 

RESOURCE-WRITE,  — > RESOURCE-REPLY, 


VII.2  — Readers- Writers  Scheduling  Specifications 

Variations  of  the  readers-writers  problem  derive  from  the  desirability  of  imposing  stronger 
scheduling  specifications  than  simply  that  the  serializer  must  reply  to  requests  that  it  receives.  Note  that 
readers  do  not  interfere  with  one  another  even  if  they  are  executing  in  parallel  in  the  protecteo 
resource.  Therefore  allowing  multiple  readers  into  the  resource  concurrently  can  increase  thruput. 
Several  variations  of  scheduling  specifications  that  require  more  concurrency  will  be  presented  below. 
In  alt  of  these  implementations  we  will  keep  track  of  whether  there  are  readers  in  the  resource  or  there 
is  a writer  in  the  resource  by  keeping  a separate  crowd  for  the  readers  and  a separate  crowd  for  the 
writer  (which  will  never  have  more  than  one  member). 

Below  we  will  present  several  implementations  of  the  readers-writers  problems  in  which  readers  is 
the  crowd  of  readers  in  the  protected  resource  and  writer  is  the  crowd  of  writers  in  the  protected 
resource.  The  following  invariants  are  relevant  to  understanding  all  of  the  implementations  to  be 
presented  below: 


,he  ii*«  of  the  writer  crowd  l»  never  greater  than  one 

the  readers  crowd  and  the  writer  crowd  are  never  both  nonempty  at  the  tame  time 
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The  fact  that  all  of  the  above  invariants  are  preserved  will  be  immediately  evident  from  inspection  of 
the  code  of  all  the  implementations  given  below.  No  complicated  chain  of  reasoning  will  be  required. 
This  is  an  example  of  how  properties  of  a scheduler  implemented  using  serializers  can  be  seen  with 
greater  perspicuity  than  is  possible  from  implementations  using  leu  structured  arbitration  primitives 
such  as  semaphores. 


VII.3  — Writer  Exoludes  Others 

Let  us  introduce  no  new  constraints  beyond  the  primary  one  of  insisting  that  a writer  has  sole 
access  to  the  resource.  One  possible  implementation  that  would  satisfy  those  constraints  is  the 
one-at-a-time  serializer  presented  above.  Another  implementation  follows  that  would  allow  readers  to 
access  the  resource  concurrently. 


In  the  implementation  below  we  provide  that  a resource  which  is  to  be  scheduled  for  reading  and 
writing  will  receive  messages  of  the  form  (read  (using:  directions))  and  (write  (using:  directions)).  The 
directions  included  in  these  messages  can  be  as  complicated  as  desired  up  to  and  including  an  arbitrary 
procedure  for  carrying  out  the  transaction  on  the  protected  resource  without  side  effects.  Note  that  this 
degree  of  generality  in  the  directions  can  complicate  verifying  that  the  resource  will  reply  to  each  request 
which  it  is  sent.  Nevertheless,  in  the  discuuion  below  we  will  auume  that  the  resource  will  always  reply 
to  requests  of  the  form  (read  (using:  directions))  and  (write  (using:  directions)). 


((writer_exclude_others  =t  he  .resource)  s 

(create  _scrializer 
(queues:  readers.q  writers_q) 

(crouds:  readers  writer) 

(entry: 

(cases 

(=>  (read  (using:  sdirections)) 
(enqueue  reader s_q 

(guarantee:  (empty,  writer)) 
(then: 


;a  serializer  which  enforces  that  writer*  excludes  others 
ifrom  the  resource  is  implemented  by  constructing 

;a  serializer  which  has 
;two  queues  called  readers.q  and  writers.q 
;two  crowds  called  readers  and  writer 

{after  entry 

; there  are  two  cases  for  the  message 
{receive  a request  to  read  the  resource  using  directions 
{enqueue  on  the  readers  queue  to 
ifuerontee  that  there  is  no  writer  in  the  resource 

;when  dequeued, 
i deliver  the  message  to  the  resource 


( relay_to  the_resource 

( message : ( read  (using:  directions))) 

(thru:  readers)))))  ; passing  thru  the  readers  crowd 

(=>  ( write  (using:  =directions))  {receive  a request  to  write  in  the  resource  using  directions 

(enqueue  writers.q  {enqueue  on  the  writers.q  to 

(guarantee:  (empty  readers  writer)) 

{guarantee  that  there  are  neither  readers  nor  a writer  in  the  resource 
(then:  {when  dequeued, 

(relay_to  the  .resource  {deliver  the  message  to  the  resource 

( message : (write  (using:  directions))) 

(thru:  writer)))))))))  {passing  thru  the  writer  crowd 


It  is  easy  to  see  that  the  above  implementation  guarantees  that  writers  will  exclude  others  from 
the  resource  since  if  there  is  an  element  in  the  writer  crowd  then  all  the  queues  of  the  serializer  are 
blocked. 


I 
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((six*  writer)  i 1) 

<*/  ( nonempty:  writer)  then  (empty:  reader*)) 

However,  the  above  implementation  does  not  satisfy  the  requirement  that  the  serializer  must  always 
reply  to  requests  which  it  receives  since  nothing  forces  the  readers  crowd  to  eventually  become  empty.  If 
the  readers  crowd  does  not  empty  then  a writer  could  be  stuck  forever  in  writers.q  (this  problem  has  its 
roots  in  the  violation  of  our  recommendation  that  no  two  processes  should  be  "ready  to  go"  in  a 
serializer  at  the  same  time).  Therefore  the  above  implementation  must  be  refined  or  interpreted  in 
some  way  in  order  to  meet  the  specifications. 


VII.4  — First  Come  First  Served 


The  implementation  given  below  satisfies  the  specification  that  the  protected  resource  is  served  on 
a first  come  first  served  basis.  In  addition,  starvation  is  not  possible  with  the  first.come.firstjserved 
serializer  and  a certain  amount  of  concurrency  is  guaranteed.  Note  that  the  additional  specification 
results  in  an  implementation  that  is  simpler  than  the  previous  one.  The  added  simplicity  is  due  to  the 
ability  of  serializers  to  have  processes  waiting  in  a single  queue  for  different  conditions. 


((first.come.first.served  =the_resource)  s 

(create  serializer 

( queue s:  waiting.q) 

(crowd*:  readers  writer) 

(entry: 

(cases 

(=>  (read  (u*ing:  ^directions)) 
(enqueue  waiting.q 

(guarantee:  (empty,  writer)) 
(then: 


;a  firtt  come  firtt  terved  i rialiter  of  the  retource  which 
;can  be  implemented  by  constructing 
;a  serializer  which  ha* 
;a  queue  called  the  waiting.q 
;and  two  crowds  called  reader*  and  writer 

;after  entry 

; there  are  two  cases  for  the  message 
;receive  a request  to  read  the  resource  using  directions 
ienqueue  on  the  wailing  queue  to 
; guarantee  that  there  is  no  writer  in  the  resource 

;i ehen  dequeued, 
; deliver  the  message  to  the  resource 


(relay_fo  the  .resource 

(message:  (read  (using:  directions))) 

(thru:  readers)))))  ;passing  thru  the  readers  crowd 

(=>  (write  (using:  ^directions))  ;receive  a request  to  write  in  the  resource  using  directions 

(enqueue  waiting.q  ienqueue  on  the  waiting  queue  to 

(guarantee:  (empty,  readers  writer)) 

Iguarantee  that  there  are  neither  readers  nor  a writer  in  the  resource 
(then:  ;when  dequeued, 

(relay_to  I be  .resource  ; deliver  the  message  to  the  resource 

(message:  (write  (using:  directions))) 

(thru:  writer)))))))))  thru  the  writer  crowd 
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VH  4a  — Requiring  Concurrency  in  Implementations 

In  the  readers-writers  problems  there  Is  a basic  integrity  constraint  that  the  serializer  must 
maintain,  which  is  to  ensure  that  a writer  does  not  have  access  to  the  resource  at  the  same  time  as  any 
other  requestor.  However,  a simple  one-at-a-time  approach  can  easily  guarantee  this  property.  The 
more  complex  versions  of  the  problem  attempt  to  provide  readers  with  concurrent  access  to  the  resource 
without  starving  the  writers.  When  we  say  that  some  amount  of  concurrency  is  guaranteed,  we  mean 
that  the  specifications  for  the  serializer  require  that  certain  readers  be  given  the  opportunity  to  access 
the  resource  at  the  same  time. 

Note  that  a serializer  cannot  guarantee  that  the  requests  to  a protected  resource  are  actually 
processed  in  parallel,  since  either  the  structure  of  the  resource  or  some  externally  defined  scheduling 
policy  may  prevent  actual  parallelism.  We  say  that  readers  Rj  and  Rj  are  concurrent  readers  if 

JOIN-CROWDj  ~>  LEAVE-CROWD: 

and 

JOIN-CROWDj  ~>  LEAVE-CROWDj 

The  specifications  for  the  first-come-first-serve  serializer  include  a requirement  for  concurrency. 
We  can  informally  express  this  requirement  as  saying  that  whenever  one  reader’s  entry  into  the 
serializer  (an  ENTRY  event)  immediately  precedes  another  reader’s  entry,  and  the  second  reader  enters 
the  serializer  before  the  first  reader  enters  the  resource  (a  JOIN-CROWD  event),  then  these  two  readers 
must  concurrently  be  in  the  resource.  We  can  also  give  a more  formal  specification  in  terms  of  events: 

It  Rj  and  Rj  are  readers  such  that 
ENTRY;  ~>  ENTRYj  ~>  JOIN-CROWDj 
and 

there  is  no  requestor  Xk  (a  reader  or  writer)  such  that 
ENTRYj  — > ENTRYK  — > ENTRYj 

then  Rj  and  Rj  must  be  concurrent  readers,  i.e. 

JOIN-CROWDj  — > LEAVE-CROWDj 

and 

JOIN-CROWDj  — > LEAVE-CROWDj 

Note  that  the  above  requirement  would  be  the  same  if  we  required  that  the  requestor  Xk  be  a writer, 
although  the  proof  would  be  somewhat  more  difficult. 
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V11.4.b  — Proof  of  Guaranteed  Concurrency 

A proof  that  the  first_come_first_served  serializer  shown  above  satisfies  the  given  concurrency 
requirement  proceeds  by  assuming  the  existence  of  two  readers  with  the  given  relationship,  then 
showing  that  they  must  be  concurrent  readers.  Since  we  have 

ENTRYj  ->  ENTRYj  ~>  JOIN-CROWDj 

we  know  that  the  reader  Rj  must  be  in  the  waiting_q  when  the  reader  Rj  gains  possession  of  the 
serializer.  Rj  must  be  enqueued  directly  behind  Rj,  since  by  our  assumptions  there  are  no  intervening 
entries  to  put  other  requestors  in  the  waitingjq.  Therefore  when  reader  Rj  does  get  into  the  resource 
through  a JOIN-CROWD  event  (thereby  releasing  possession  of  the  serializer),  then  the  requestor  at  the 
head  of  the  waiting_q  must  be  Rj  and  the  condition  of  ( empty,  writers)  must  be  true.  We  then  appeal  to 
the  priority  which  serializers  give  to  processes  waiting  in  interal  queues  of  the  serializer. 

JOIN-CROWDj  ~>  LEAVE-CROWDj 

Since  we  know  that  JOIN-CROWDj  -->  JOIN-CROWDj,  and  JOIN-CROWD,  -->  LEAVE-CROWD,, 
we  conclude  that  JOIN-CROWD,  -->  LEAVE-CROWDj,  which  completes  the  proof  that  R,  and  Rj  are 
concurrent  readers.  J 


VII.5  — Readers  Priority 

The  following  serializer  forces  readers  into  the  resource  concurrently.  However,  we  need  to  guard 
against  starvation.  Our  approach  is  to  allow  all  waiting  readers  to  enter  the  resource,  then  to  designate 
the  writer  which  has  been  waiting  as  the  new  privileged  writer,  and  keep  further  readers  from  entering 
the  resource  until  the  privileged  writer  has  relayed  its  message  to  the  resource.  After  the  privileged 
writer  has  been  served,  then  all  readers  which  have  been  waiting  for  that  writer  to  finish  are  allowed  to 
enter  the  resource,  and  a new  privileged  writer  is  chosen.  A reader  may  not  deliver  a message  to  the 
resource  while  there  is  a privileged  writer,  or  there  is  a writer  in  the  resource.  A writer  may  not  enter 
the  resource  unless  it  is  a privileged  writer,  and  there  are  neither  readers  nor  a writer  in  the  resource. 
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((read.concurrently  =the_rasource)  = 


(r  rea  I e_serializer 
((jttcuf*:  readers.q  wrilers.q) 
(crowds:  readers  writer) 

(entry: 

(cases 

(=>  (read  (using:  =directions)) 

( enqueue  readers.q 

( guarantee : ( empty,  writer)) 
(then: 

( relay_to  the_resource 


;a  serializer  which  enforces  concurrency  among  readers  of 
;lhe  resource  is  implemented  by  constructing 
;a  serialiser  which  has 
ittoo  queues  called  readers.q  and  writers_q 
;tsoo  crowds  called  readers  and  writer 

; after  entry 

{there  are  two  cases  for  the  message 
{receive  a request  to  read  the  resource  using  directions 
{enqueue  on  the  readers  queue  to 
{guarantee  that  there  are  no  writers  in  the  resource 

{when  dequeued, 
{deliver  the  message  to  the  resource 


( message : ( read  (using:  directions))) 

(thru:  readers)))))  {passing  thru  the  readers  crowd 

(s>  (write  (using:  =directions))  {receive  a request  to  write  in  the  resource  using  directions 

(enqueue  writers.q  {enqueue  on  the  writers  queue  to 

(guarantee:  (empty:  readers.q  writer)) 

{guarantee  that  readers.q,  and  writer  crowd  are  all  empty 
(then:  {when  dequeued, 

(enqueue  readers.q  {enqueue  on  readers.q  to 

(guarantee:  (empty,  readers  writer)) 

{guarantee  that  there  are  neither  readers  nor  a writer  in  the  resource 
(then:  {when  dequeued, 

(relay _to  the_resource  {deliver  the  message  to  the  resource 

(message:  (write  (using:  directions))) 

(i  ftru:  writer)))))))))))  {passing  thru  the  writer  crowd 


The  above  implementation  is  a little  more  complicated  than  the  previous  one.  However,  it  is  not 
difficult  to  show  that  writers  exclude  others  using  the  technique  used  for  the  previous  implementation 
since  the  following  invariants  are  maintained: 


((size  writer)  S 1) 

(if  (nonempty,  writor)  then  ( empty  readers)) 


In  order  to  show  that  neither  readers  or  writers  can  possible  starve,  consider  the  following  "traffic 
diagram"  for  the  queues  and  crowds  of  the  serializer: 
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Entering  readers 


I I 

V V 

reader s_q 


Entering  writers 

I 

I 

V 

writers  q 

I 

I 

+ + 

I 

(empty:  readers_q  writer) 


(empty:  readers)  | 

I 

+ + 


I 

+- 


(empty:  readers  writer) 


-+ 

I 

I 


V 

readers 


V 

wr  i ter 


Traffic  Diagram  for  Queues  and  Crowds  of  read.concurrently 

The  idea  of  the  proof  is  to  first  show  that  the  readers_q  must  eventually  empty,  then  to  show  that  any 
writer  in  the  writerc.q  must  eventually  migrate  to  the  readerajq.  These  two  conditions  ensure  that  every 
read  or  write  request  to  the  serializer  is  eventually  satisfied. 


VH5.a  — Proof  that  the  Readers  Queue  Must  Empty 

If  there  is  a privileged  writer  in  the  readerajq,  theh  there  is  only  one  such  writer,  and  it  must  be 
at  the  head  of  the  queue.  A writer  can  only  enter  the  raadari.q  after  it  has  been  dequeued  from  the 
writers.q,  and  the  guarantee  of  every  writer  exiting  the  wrltersjq  is  that  the  readerajq  is  empty.  Thus, 
not  only  is  it  true  that  there  may  be  only  one  writer  in  the  reedersjq,  the  writer  must  also  be  at  the  head 
of  the  queue  if  it  is  there. 

Processes  may  only  enter  the  readers  crowd  or  the  writer  crowd  by  first  exiting  the  readers_q.  We 
have  assumed  that  the  .resource  is  correct  in  that  every  message  sent  to  the  resource  will  eventually 
produce  a single  reply.  Therefore,  if  a writer  is  at  the  head  of  the  readerajq,  it  is  guaranteed  that  no 
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messages  will  be  sent  to  the_r*source  from  the  serializer  until  both  the  reader*  crowd  and  the  writer 
crowd  are  empty. 

By  a similar  argument,  if  a reader  is  at  the  head  of  the  readersjq,  the  writer  crowd  must 
eventually  empty,  which  implies  that  a reader  at  the  head  of  the  read*r«_q  must  eventually  exit  the 
queue  Once  a single  reader  is  dequeued  from  the  readars_q  all  readers  in  the  readers  q in  front  of  a 
wmer  must  be  dequeued.  For  any  reader  in  the  readers.q  an  event  of  the  form 
ESTABLISH EDrt)8ders  q must  be  followed  by  an  event  of  the  form  JOIN-CROWD.-.^...  For  every 
such  JOIN-CROWD  event,  the  serializer  is  released,  and  if  the  raadars.q  has  a reader  at  its  head,  that 
reader  must  be  dequeued,  since  the  raadar_q  is  the  only  Internal  queue  with  it*  guaranteed  condition  true 
(the  writer  crowd  remains  empty). 

Thus,  we  have  shown  that  all  readers  must  exit  the  readersjq  if  they  occur  before  a writer  in  that 
queue  or  if  there  is  no  writer  in  that  queue.  Further,  if  a writer  is  at  the  head  of  the  reader*  q then  it 
also  must  exit  the  readers.q.  Once  a writer  exits  the  re*ders„q  there  may  be  no  additional  writers  added 
to  that  queue  until  it  is  empty.  Therefore,  the  r**derc_q  must  empty. 


VII.5.b  — Proof  That  No  Process  in  the  writer»_q  Can  Starve 

The  idea  behind  this  proof  is  simple.  Any  writer  in  the  writer*_q  is  waiting  for  both  the  writer 
crowd  and  the  readers.q  must  empty.  By  our  assumption  about  the  resource  there  must  be  a 
RESOURCE-REPLY  message  for  any  writer,  so  the  writer  crowd  must  empty.  We  have  just  proved 
above  that  the  readers.q  must  empty.  Therefore  the  process  at  the  head  of  the  writers.q  must 
eventually  be  dequeued,  which  is  sufficient  to  show  that  no  process  in  the  writerajq  can  starve. 


VH.5.C  — Requiring  Concurrency  for  Reader’s  Priority 

The  readers-priority  serializer  is  intended  to  give  more  thruput  to  readers  at  the  expense  of 
writers,  while  still  guaranteeing  that  each  write  request  will  receive  a reply.  Our  informal  requirement 
is  whenever  one  reader’s  entry  into  the  serializer  follows  another  reader’s  entry  (regardless  of 
intervening  serializer  entries),  and  the  second  reader  enters  the  serializer  before  the  first  reader  enters 
the  resource,  then  the  two  readers  are  concurrent  within  the  resource.  In  terms  of  events,  this 
requirement  can  be  expressed  as: 

If  Rj  and  R-  ara  readart  such  that 

ENTRYj  — > ENTRYj  — > JOIN-CROWDj 
than  Rj  and  Rj  must  ba  concurrent  readers,  i.a. 

JOIN-CROWDj  — > LEAVE-CROWDj 
and 

JOIN-CROWDj  — > LEAVE-CROWDj 
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Note  that  the  above  requirement  is  stronger  than  the  concurrency  requirement  given  for 
first_com#_fir*t_*#rvad. 

All  readers  that  have  entered  the  serializer  and  not  yet  in  the  resource  are  in  the  r#adar*_q,  and 
the  only  writer  that  can  be  in  the  readertjq  must  be  at  the  head  of  the  queue.  We  have  previously 
shown  that  once  one  reader  can  leave  the  reader* _q  then  all  must  leave  the  reader*_q  and  enter  the 
resource.  We  note  that  by  the  axiom  of  giving  internal  queues  priority  over  external  queues  all  readers 
in  the  readers.q  must  enter  the  resource  before  any  reply  from  the  resource  will  enter  the  serializer 
(through  a LEAVE-CROWD  event).  This  completes  the  proof. 
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SECTION  VIII  — ANALYSIS  of  SERIALIZERS 


VIH.l  — Comparison  with  Monitors 

Serializers  are  generalizations  of  the  "secretary"  concept  which  was  conceived  by  Dijkstra  and 
later  developed  into  "monitors"  by  Brinch-Hansen,  and  Hoare.  The  purpose  of  serializers  is  to  schedule 
access  to  shared  resources  in  order  to  protect  their  integrity.  Roughly  speaking,  serializers  are  analogous 
to  monitors  in  the  same  way  that  actors  are  analogous  to  SIMULA-67  classes.  A serializer  is  an  actor 
that  will  allow  only  one  process  to  have  possession  at  a time  whereas  a monitor  is  a SIMULA-67  class 
that  will  allow  only  one  process  to  be  executing  inside  it  at  a time.  A general  principle  of  efficient 
operation  that  is  applicable  to  both  serializers  and  monitors  is  to  try  to  keep  the  serializer  [monitor) 
unlocked  as  much  of  the  time  as  possible  to  keep  it  from  being  a bottleneck  in  the  operation  of  a larger 
system. 

We  believe  that  serializers  are  easier  to  write  and  verify  in  a modular  fashion  than  monitors. 
The  correctness  of  a serializer  is  independent  of  the  way  in  which  it  is  used.  It  is  more  difficult  to 
verify  the  correctness  of  a monitor  since  the  ordering  of  monitor  operations  and  access  to  the  protected 
resource  is  dependent  on  the  programs  using  the  monitor.  Serializers  support  modular  programming 
better  than  monitors  because  serializers  can  be  sensibly  nested  inside  one  another  whereas  usually  it  is 
unprofitable  to  nest  one  monitor  inside  another  because  the  outer  monitor  will  be  tied  up  while  the 
inner  one  is  in  use.  A further  advantage  for  serializers  is  that  use  of  a protected  resource  appears 
identical  to  the  use  of  the  unprotected  resource  in  a program  that  uses  the  resource. 

Using  serializers  the  condition  associated  with  an  enqueue  command  is  explicitly  stated  in  the  code 
of  the  implementation  whereas  the  conditions  used  in  the  WAIT  statement  in  a monitor  are  syntactic 
constructs  which  do  not  explicitly  state  what  condition  must  be  guaranteed  in  order  to  proceed.  A 
process  which  needs  to  wait  for  some  condition  to  be  guaranteed  before  it  proceeds  explicitly  states  the 
condition  in  the  serializer.  In  our  experience  this  feature  lessens  the  number  of  internal  queues  and 
tends  to  simplify  program  proofs. 

Another  difference  is  the  use  of  crowds  rather  than  counters  to  keep  track  of  processes  that  have 
been  allowed  to  access  the  encapsulated  resource.  While  there  is  an  additional  cost  associated  with  such 
accounting,  we  believe  that  the  benefits  will  make  the  use  of  crowds  a decided  advantage.  It  is  possible 
to  examine  the  crowds  to  determine  which  processes  are  currently  accessing  which  resources.  We  expect 
that  this  will  have  significant  impact  on  debugging  programs  that  use  parallel  processes.  Furthermore, 
if  some  process  must  be  terminated  externally,  then  the  resources  it  is  accessing  can  be  reclaimed  in  a 
modular  fashion. 

Axioms  about  monitors  and  implementation  of  monitors  are  both  made  more  difficult  by  the 
necessity  of  having  an  "urgent  queue".  Proofs  of  programs  using  the  SIGNAL  statement  are  made 
more  complicated  by  the  necessity  of  considering  the  possible  effects  of  processes  emerging  from  the 
urgent  queue.  Hoare  states  in  his  paper  on  monitors  that  he  considers  it  to  be  good  practice  to  exit  a 
monitor  immediately  after  a SIGNAL  statement.  We  consider  it  to  be  a practice  worthy  of  enforcement. 
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All  internal  queues  in  a serializer  are  explicit,  and  explicit  signals  do  not  occur  Rather  the  condition* 
for  emerging  from  a queue  are  explicitly  listed  at  the  point  of  enqueuing.  conditions 
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SECTION  IX  — MORE  GENERAL  SERIALIZERS 

Serializers  need  to  be  generalized  in  several  ways  in  order  to  be  a general  purpose 
synchronization  mechanism. 

Thus  far  in  this  paper  we  have  restricted  our  attention  to  serializers  which  use  first-in  first-out 
queues  as  the  mechanism  for  scheduling  the  release  of  processes  waiting  for  some  condition.  It  is 
necessary  to  generalize  this  mechanism  in  order  to  conveniently  solve  certain  scheduling  problems.  For 
example  Hoare  has  used  priority  queues  to  solve  the  disk  head  scheduling  problem.  Below  we  present 
an  implementation  of  a virtual  disk  which  efficiently  schedules  disk  accesses  to  a real  physical  disk. 
The  operations  on  the  virtual  disk  are  exactly  the  same  as  the  ones  defined  on  the  physical  disk.  The 
implementation  given  below  uses  an  algorithm  similar  to  one  used  by  Hoare  in  an  implementation  using 
monitors.  However,  it  will  be  possible  to  prove  that  our  implementation  using  serializers  always 
performs  all  disk  operations  which  are  requested.  It  is  not  possible  to  prove  this  property  for  the 
implementation  using  monitors  because  a process  might  request  the  disk  and  then  never  release  it. 
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((virtual-disk  =physical.disk)  s {a  virtual  disk  behaves  like  a physical  disk  with  optimised  head  motion 
<f«*  tie  t 

(current-position  initially  0)  ;i he  current  position  initialised  to  0 

(current-direction  initially  up)  ;t he  current  direction  of  motion  is  initially  up 

then 

(create  _scrializcr  ; create  a serialiser  tcith 

(priority _qu.cu.ct:  up.queue  down.queue)  ;t too  priority  queues 

( crouds : disk-users)  ;on«  crowd 

(entry.  ;after  gaining  possession 

(s>  (disk_request  ( operation : *op)  (track:  *trackjium)) 

; receive  disk  request  tcith  specified  operation  and  track  number 
(let  ; define  the  procedures  wait-up  and  wait-down  as  follows 

((wait-up)  s ;i he  procedure  wait_up  is  defined  as  follows 

(enqueue  up.queue  (priority:  trackjiumber) 

.enqueue  in  the  up  queue  tcith  priority  given  by  the  track  number 
(guarantee:  ;to  guarantee  that 

(and  (empty:  disk-users)  ,-no  ona  is  using  the  physical  disk 

(or  (empty:  down.queue)  ;and  that  either  the  down  queue  is  empty 

(current-direction  = up))))  ;or  an  upsweep  is  in  progress 

(then:  (current-position  «-  trackjiumber)  ;t hen  update  the  position 

(current-direction  *•  up) 

(relayjto  physical-disk  {relay  the  request  to  the  physical  disk 

(message:  (disk_request  (operation:  Op)  (track:  track_num)) 

(thru:  disk-users))))))  {passing  thru  the  disk  users  crowd 

((wait-down)  s {the  procedure  wait-down  is  defined  as  follows 

(enqueue  down_queue  {enqueue  in  the  down  queue 

(priority,  (number.of.tracks  - treck_number)) 

(guarantee: 

(and  (empty:  disk-users)  (or  (empty,  up.queue)  (current-direction  ■ down)))) 
(then:  (current-position «-  track-number) 

(current-direction «-  down) 

(relay_fo  physical-disk 

(message:  (request  (operation:  op)  (track:  trackjium))) 

(thru:  disk-users))))) 

then 

(rules  track-number  {if  the  track  number  is 

(=>  (>  current-position)  (wait.up)) 

{greater  than  the  current  position  then  wait  in  the  up  queue 
(s>  current-position  {else  if  the  track  number  is  the  same  as  the  current  position 
(rules  current-direction  {then  if  the  current  direction 

(=>  up  (wait-down))  {is  up  then  wait  in  the  down  queue 

(=>  down  (wait-up))))  {else  wait  in  the  up  queue 

(=>  « current-position)  (waitjdown))))))))) 

{else  if  the  track  number  is  less  than  the  current  position  then  wait  in  the  down  queue 
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arrnmld fT?  u a*ove  ,mPlerne"tati0"  a>way*  performs  disk  operations  which  are  requested  is 
accomplished  by  showing  that  the  disk  head  sweeps  the  disk  in  both  the  upward  and  the  downward 

direction  servicing  all  requests  for  the  tracks  which  it  passes  over.  There  are  two  cases  to  the  proof: 


Case  I.  One  of  the  queues  is  empty.  This  means  that  any  requests  in  the  other  queue  are 
served  in  order  of  smallest  priority  number.  All  of  the  requests  will  be  served  because 
any  new  entries  in  the  nonempty  queue  must  have  higher  priority  numbers  than  the 
lowest  priority  number  already  in  the  queue.  The  priority  numbers  are  bounded  above 
by  the  number  of  disk  tracks.  Since  the  internal  queues  of  a serializer  have  absolute 
priority  for  next  possession  of  the  serializer  over  external  requests,  it  follows  that  only 
finitely  many  new  requests  can  enter  a queue  during  each  physical  disk  operation. 
Therefore  if  one  of  the  queues  remains  empty  then  the  other  will  eventually  empty 


Case  2:  Both  the  up.quouo  and  the  down.quouo  are  nonempty.  The  queue  to  be  served  is 
determined  by  the  curr#nt_diroc»lon.  The  argument  used  in  Case  ! can  be  used  to  show 
that  if  curr.nt_dir.ction  is  up  then  it  will  remain  up  until  up_qu.u.  has  emptied  and 
curr.nLd.r.clion  will  then  be  changed  to  down.  An  analogous  result  to  the  previous 
statement  holds  with  up  replaced  by  "down".  r 
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SECTION  X — FUTURE  WORK 

The  simple  specification  that  "starvation  is  prohibited"  is  common  to  almost  all  synchronization 
specifications.  Yet  serializers  at  present  make  no  such  guarantee.  They  do  make  it  easier  to  prove  that 
an  implementation  using  a serializer  is  free  of  the  danger  of  starvation  by  facilitating  the  proof  that 
the  serializer  always  replies  to  requests  which  it  receives.  We  feel  that  research  should  continue  to 
search  for  mechanisms  that  provide  effective  guarantees  of  such  properties,  yet  also  provide  sufficient 
generality  to  cope  with  a wide  range  of  problems. 

Serializers  have  potential  for  use  in  robust  systems  in  that  more  Information  is  available  for  error 
recovery.  The  additional  information  is  useful  for  implementing  debugging  features,  deadlock 
detection,  and  gracefully  backing  processes  out  of  protected  resources. 
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SECTION  XI  — CONCLUSIONS 

emeraluatmn^nT,  ^ ^ intro*'iC*d  a modu,ar  "**»“«»  primitive  called  a serializer  which  is  a 
generalization  and  improvement  of  the  monitor  construct  previously  developed  by  Brinch-Hansen  and 

::d  Te  tt  ofrd“i,r  •*««  s? 

senalize?  2 T spcc»f 'or  useful  synchronizers.  The  structure  imposed  by  using 
specif, canons  'mP°rtam  gUaranteK  that  a‘d  *"  Provi"*  ,hat  *•  ‘n,plemenSZ  meet,  Us 

the  ™:rSpeC,f,Cati°nS  f°[/  serla,iIer  inc,ude  integrity  specifications  relating  the  order  of  access  to 
type  of  access,  and  scheduling  specifications  to  ensure  that  differing  types  of  access  occur  in  the 
proper  order.  Part  of  this  ordering  specification  included  a specif icat  on  requir  ng  Z certl^n 
requestors  must  be  given  the  opportunity  to  use  the  resource  ^currently.  In  the  readers-wmer, 
serializer,  we  gave  the  integrity  specifications  that  readers  and  writers  were  mutually  exclusive  in 
accessing  the  resource,  and  that  at  most  one  writer  could  access  the  resource  at  a 
solutions  to  the  readers-writers  problem  resulted  from  different  scheduling  specifications. 

svnrhr2e  IT'  *°  intrt>duce  faci,ltles  int0  seriali««  that  directly  correspond  to 

or  write?  h specifications.  The  constraint  that  the  resource  is  not  being  accessed  by  either  readers 
or  writers  when  a writer  enters  is  explicit  in  the  code  of  our  implementations,  as  is  the  requirement  that 

wamn ToZ'  3Crng  tHJ  reS°UrCe  WhCn  8 feader  enter*  *e  condition  for  a 

waiting  process  to  proceed  ,s  explicitly  stated.  In  this  way  integrity  specifications  can  be  directly 

expressed  in  the  language.  Scheduling  specifications  are  more  complicated.  We  have  been  able  to  use  a 

specifications  ^Furth^  par“a'  ^ am°"g  eVenU  to  ^ effect  to  express  scheduling 

specifications.  Furthermore,  the  structure  of  the  serializers  has  enabled  us  to  give  simple  intuitive 

proofs  that  various  scheduling  specifications  are  satisfied  by  implementations  that  use  serializers 
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